進口食品抽驗不可能每一箱、每一顆蘋果都切開做最高規格的農藥檢測；若什麼都採最高標準，物流成本也會飆破天際。
軟體測試也是同理：開發團隊受限於時程與人力預算，不可能對所有系統模組都套用最高規格的檢驗。隨機無序的測試既缺乏效率也無法證明安全性。本篇聚焦在測試前期的「規劃」核心思維——如何透過風險分析挑出最關鍵的檢查點，把有限的測試資源精準砸在刀口上。
這場測試到底想達成什麼目的？（例如：「確保這次的系統能通過 PCI DSS 發卡組織稽核」，或是「保證在軟體正式發佈前，絕對不能殘留任何 OWASP Top 10 的漏洞。」）
要在哪裡花多少力氣測試、測試要多廣挖多深，完全取決於該應用程式的風險概況 (優先排序)。
高風險應用程式 (High Risk App)（例如：牽涉金流的金融交易系統）：必須包含 SAST, DAST, IAST, 人工程式碼細部審查，再外加上花錢請外部第三方團隊來打滲透測試 (penetration testing)。
低風險應用程式 (Low Risk App)（例如：純內網觀看、不牽涉個資的員工餐廳每週菜單系統）：可能只需要設定跑個自動化的 SAST 跟 DAST 掃描交代一下就夠了。
策略文件中必須明確點出，這次的測試將對齊並遵從哪些業界公認標準
| 測試類型 | 說明 |
|---|---|
| 白箱測試 (White-Box Testing) | 在對系統內部架構與原始碼瞭若指掌 (甚至擁有原始碼) 的情況下進行的測試 (例如：SAST 工具掃描、人工作業的原始碼逐行審查)。 |
| 黑箱測試 (Black-Box Testing) | 對系統內部運作邏輯一無所知，完全瞎子摸象般站在外部駭客視角發動攻擊的測試 (例如：DAST 動態掃描、外部滲透測試)。 |
| 灰箱測試 (Gray-Box Testing) | 具備一定程度的內部情報 (例如：雖然沒有原始碼，但測試者擁有登入帳號密碼，能以一般使用者身分從內部觀察系統反應) 所進行的測試 (例如：IAST 互動式掃描、已身分驗證的 DAST 掃描)。 |
| 模糊測試 (Fuzz Testing) | 故意亂塞一堆無效的、格式錯亂的、或是隨機亂數的垃圾資料餵給系統，企圖把它搞崩潰或誘發例外狀況 (exception)。 |
| 迴歸測試 (Regression Testing) | 針對以前曾經發現過、且宣稱已經被修好的舊漏洞「重新再測一次」，為了是確保新修改的程式碼沒有不小心又把這些老病根給喚醒 (reintroduced)。 |
OWASP ASVS
(應用程式安全驗證標準 Application Security Verification Standard)
https://owasp.org/projects/asvs
NIST SP 800-115
(資訊安全測試與評估技術指南 Technical Guide to Information Security Testing and Assessment)
https://csrc.nist.gov/pubs/sp/800/115/final
OSSTMM
(開源安全測試方法論手冊 Open Source Security Testing Methodology Manual)
https://www.isecom.org/research.html
iThome鐵人賽
看影片追技術